In object-oriented technique field, Unified Modeling technique is one of the most important techniques currently in use. In 1997, Object Management Group (OMG) issued Unified Modeling Language (UML). UML is a modeling language having various functions and is well defined, easy to express, and widely used. Not only does it support object-oriented analysis and design, but also, and more importantly, it supports the whole procedure of software development beginning from demand analysis. One object of UML is to provide a development team with a universal design language to develop and construct computer applications. UML offers a set of unified standard modeling symbols, so that IT professionals can perform the modeling of computer applications. Using UML, the professionals can read and discuss system architectures and design layouts, like construction layouts used by architects for many years.
One reason that UML has become a “standard” for modeling language is that it is independent of program design language. Moreover, the UML symbol set is only a kind of language rather than methodology. This is critical, since a language differs from a methodology in that a language can easily fit some business operation of any company without any alteration. UML offers various types of model description figures. When these figures are used in a certain methodology, it makes the application program in development more easily understood. By representing a project with standard UML figures, a person skilled with UML may more easily understand the project and get in character. The common-used UML figures comprise: instance figure, class figure, sequence figure, status figure, activity figure, component figure, layout figure, and etc.
Taking the above as an example, high level models are transformed to low level models after their construction. Such a situation exists in the development process for various model-driven solutions. Then, the solution developer may change the transformed low level model by way of refinement, enhancement, optimization, and implementation. However, such changes in low level models usually cannot be reflected to high level models for the following reasons:
1) High level models and low level models are at different abstraction levels, so some low level changes are too trivial to be reflected to high level models.
2) For complex and large scale solution development, multiple solution developers are involved and the person taking charge of high level models is usually not those taking charge of low level models. Therefore, the latter might not communicate with the former about the changes to low level models.
3) Even if the above reason 2) is well-solved, reverse transformation of the changed low level models is needed. However, the reverse transformation is very difficult if not impossible.
Thus, it is seen from the above, there is a gap between the original high level models and the post-change low level models, i.e., low level models that have been changed after being created from original, high level models. Furthermore, with a change in requirements, original high level models have to be changed. Accordingly transformation should be done again to reflect the new changes to low level models.
The above description will be much clearer by referring to FIG. 1, for example. FIG. 1 illustrates the technical problem to be solved, wherein, s0 represents an original high level model (i.e., pre-change high level model), t0 represents the low level model transformed from s0 (i.e., pre-change low level model), s1 represents the post-change high level model by changing s0 according to requirements, t1 represents the post-change low level model by changing t0, and t2 represents the low level model newly generated by transforming s1 while including necessary changes in t1. It can be clearly seen, how to take the existing post-change low level model t1 into consideration while transforming s1, i.e., how to present conflicts between the changes in s1 and t1 and reconcile the changes in s1 and t1 to generate the new model t2, is a big challenge, in which the main difficulties are:
1) How to judge whether the changes on high level models conflict with those existing in the low level models?
2) How to implement the compatible changes on low level models in the newly generated low level models in retransformation?
Presently, solution developers can solve these problems manually. They retransform the post-change high level model s1 to a totally new low level model t2, compare the generated low level model t2 with the post-change low level model t1 to find conflicts and identify reusable model segments, and have the changes from t0 to t1 reflect manually to t2 to eliminate the conflicts. However, this manual method has the following two obvious disadvantages:
1) The manual method requires a lot of effort and time to analyze conflicts and copy compatible changes from a post-change low level model t1 to a newly generated low level model t2.
2) Veracity and consistency of manual conflict analysis is uncertain because it mainly relies on the solution developer himself, rather than the conflict in the model transformation itself.
Therefore, it is critical to provide a method and system for analyzing and presenting conflict in the model transformation and automatically reconciling model transformation, which reduces the efforts and difficulties to adjust solution for changing requirements, saves the cost and time brought by model-driven solution development method, and improves solution quality and stability.
For complying with well-known transformation related terms, the following uses the term ‘source model’ to denote a ‘high level model’, and the term ‘target model’ to denote a ‘low level model’.
Although currently there is no method or system to support automatically reconciling model transformation, some related techniques exist, including but not limited to: 1) round trip engineering in Rational Software Architect (RSA); 2) model-code synchronization in Eclipse Modeling Framework (EMF); and 3) incremental transformation. The techniques listed above will be compared and explained item by item below.
For round trip engineering in RSA, a UML model is originally automatically transformed into code and Global Unique Identification (GUID), a unique identification code created for a certain entity, such as a document, through a particular algorithm) of model element is written in the special comment of its corresponding code element to indicate the tracing relationship between them. In this way, changes in the UML model can be automatically reflected to its corresponding code and vice versa. This approach, however, is hard to apply to reconcilable model transformation, because using a GUID to indicate a tracing relationship is not powerful enough to support complex transformation wherein multiple source elements are transformed to multiple target elements.
EMF allows users to select whether to protect some existing code from being overwritten when regenerating a changed Ecore model to code. But to do this users must judge in advance which part of the code is not conflict with the changed Ecore model.
3. Details on incremental transformation can be obtained from “Instant and Incremental Transformation of Models” (Proceedings of the 19th IEEE ICASE, Linz, Austria, Sep. 2004) by Sven Johann, Alexander Egyed. The above article addresses incremental model transformation from source model to target model, wherein only changed source model elements are re-transformed and merged to a previous target model so as to save effort. However, this approach doesn't consider a situation in which a previous target model might be changed before re-transformation.